Editor: Create own sub-registry in default EditorProvider use #15989
Conversation
aduth
requested review from
ellatrix,
gziolo,
talldan and
youknowriad
as code owners
| import { storeConfig } from '../../store'; | ||
| import applyMiddlewares from '../../store/middlewares'; | ||
|
|
||
| const withRegistryProvider = createHigherOrderComponent( |
There was a problem hiding this comment.
I feel like I already wrote this code before. Do you think there's value in exposing a generic version of this in the data module? (I'm on the fence personally)
There was a problem hiding this comment.
I feel like I already wrote this code before. Do you think there's value in exposing a generic version of this in the data module? (I'm on the fence personally)
It is identical to the one in block-editor, yes. I'm not sure either about making it generic. I'm not a huge fan of the fact we have to do a null return render, and I don't know that if that was possible to avoid, we'd be able to change it while maintaining the implementation as being a higher-order component. I was inclined to leave it for future consideration.
| @@ -91,6 +91,7 @@ class Editor extends Component { | |||
| settings={ editorSettings } | |||
| post={ post } | |||
| initialEdits={ initialEdits } | |||
| useSubRegistry={ false } | |||
There was a problem hiding this comment.
I feel this prop should be passed down from editor/provider to block-editor/provider as well right (unless we access the block-editor store from the editor components (which we probably do on a second thought but maybe we shouldn't) ?
There was a problem hiding this comment.
I feel this prop should be passed down from
editor/providertoblock-editor/provideras well right (unless we access theblock-editorstore from theeditorcomponents (which we probably do on a second thought but maybe we shouldn't) ?
Right now we just explicitly pass false:
Which I think is how we want it to be:
- If you wanted your own block editor with its own subregistry, you'd render BlockEditorProvider yourself
- If you wanted your own post editor with its own subregistry, you'd render EditorProvider which would create a subregistry. The EditorProvider would pass
useSubRegistry={ false }to its BlockEditorProvider, but that block editor still operates in the same subregistry as created for the EditorProvider
In the end, we get a flatter hierarchy of registries. For the main post editor, we still only have a single registry.
For what becomes of the embedded editor in #14715, there is a subregistry which is used both by the EditorProvider and its BlockEditorProvider.
There was a problem hiding this comment.
Makes sense, thanks for the explanation.
Extracted from #14715
Related: #14678, #14367
This pull request seeks to introduce automated sub-registry creation for the
EditorProvidercomponent. It is identical in purpose and in implementation to theBlockEditorProviderenhancements merged in #14678.This will bring consistency in editor creation, where #14715 proposes to reimplement reusable blocks using its own rendering of
EditorProviderto leverage both the blocks-editing behaviors of@wordpress/block-editor, and the post lifecycle management of@wordpress/editor.Implementation Notes:
This introduces API changes to
@wordpress/editorand@wordpress/block-editorin the form of exposing their respective base data store configurations. For additional context, this was explored and discussed previously in #14367 (comment) .Testing Instructions:
There should be no regressions in standard use of the editor.
You may place a breakpoint at any code within
@wordpress/editorwhich has access to the registry to confirm there is no effective difference in reference betweenmasterand this branch, since sub-registries should only be created when not at the top-level.